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Résumé. Les index et les vues matérialisées sont des structures physiques qui 
accélèrent l'accès aux données d'un entrepôt. Ces structures engendrent cepen- 
dant une surcharge de maintenance. Par ailleurs, elles partagent le même espace 
disque. Les travaux existants dans le domaine de la sélection d'index et de vues 
matérialisées traitent ces deux structures de manière isolée. Dans cet article, nous 
couplons au contraire la sélection d'index et de vues matérialisées de façon à 
prendre en compte les interactions entre ces structures de données et à permettre 
un partage efficace de l'espace de stockage commun qui leur est alloué. Pour 
cela, nous avons développé des modèles de coût qui évaluent le bénéfice de la 
matérialisation de vue et de l'indexation. Ces modèles de coût nous permettent, 
grâce à un algorithme glouton, de sélectionner une configuration pertinente d'in- 
dex et de vues matérialisées. Nos expérimentations montrent que notre stratégie 
se révèle meilleure que celles qui opèrent une sélection isolée des index et des 
vues matérialisées. 



1 Introduction 

Les entrepôts de données sont généralement modélisés selon un schéma en étoile contenant 
une table de faits centrale volumineuse et un certain nombre de tables dimensions représen- 
tant les descripteurs des faits Inmon (2002); Kimball et Ross (2002). La table de faits contient 
des clés étrangères vers les clés primaires des tables dimensions, ainsi que des mesures numé- 
riques. Avec ce type de modèle, une requête décisionnelle nécessite une ou plusieurs jointures 
entre la table de faits et les tables dimensions. De plus, le schéma de l'entrepôt peut compor- 
ter des hiérarchies au niveau des dimensions (schéma en flocon de neige), ce qui entraîne des 
jointures additionnelles. Ces jointures sont très coûteuses en terme de temps de calcul. Ce coût 
devient prohibitif lorsque les jointures opèrent sur de très grands volumes de données. Il est 
alors crucial de le réduire. 

Les vues matérialisées et les index sont des structures physiques qui permettent de réduire 
le temps d'exécution des requêtes en précalculant les jointures et en offrant un accès direct aux 
données. Cependant, lors du rafraîchissement de l'entrepôt de données, ces structures doivent 
également être mises à jour, ce qui engendre une surcharge pour le système. Par ailleurs, index 
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et vues matérialisées partagent le même espace de stockage. Il est donc judicieux de ne créer 
que les plus pertinents. 

Les travaux existants dans le domaine de la sélection d'index et/ou de vues matérialisées 
traitent ces deux structures de manière isolée ou séquentielle. Dans cet article, nous proposons 
une nouvelle stratégie qui opère une sélection simultanée des vues matérialisées et des index 
afin de prendre en compte les interactions entre eux. 

Dans un premier temps, nous exploitons des stratégies de sélection isolée des vues maté- 
rialisées et des index, qui nous fournissent un ensemble d'index et de vues candidats. Nous 
calculons ensuite grâce à des modèles de coût le bénéfice potentiel de chaque index et de 
chaque vue matérialisée, en prenant en compte les interactions possibles entre ces deux types 
de structures. Finalement, un algorithme glouton nous permet de sélectionner simultanément 
les vues matérialisées et les index les plus pertinents. 

Cet article est organisé comme suit. La Section 2 est consacrée à l'état de l'art de ce do- 
maine de recherche. La Section 3 présente globalement notre stratégie de sélection simultanée 
de vues matérialisées et d'index. Nous détaillons ensuite nos modèles de coût dans la Section 4, 
puis le calcul des bénéfices d'indexation et de matérialisation de vues dans la Section 5 . Nous 
présentons dans la Section 6 notre algorithme glouton de sélection simultanée de vues maté- 
rialisées et d'index. Les premières expérimentations que nous avons menées pour valider notre 
approche sont présentées dans la Section 7. Nous concluons finalement cet article et évoquons 
nos perspectives de recherche dans la Section 8. 



Le problème de sélection d'index et/ou de vues matérialisées consiste à construire une 
configuration d'index et/ou de vues matérialisées optimisant le coût d'exécution d'une charge 
donnée, supposée représentative. Cette optimisation peut être réalisée sous certaines contraintes, 
comme l'espace de stockage alloué aux index et aux vues à sélectionner. 

Plus formellement, si O = {oi, ...,o^} est un ensemble d'objets (index candidats, vues 
matérialisées candidates ou index sur les vues), Q = {gi, g'm} l'ensemble des requêtes de 
la charge et S la taille de l'espace disque alloué par l'administrateur pour stocker les objets à 
sélectionner, alors il faut trouver une configuration d'index et de vues matérialisées Config 
tel que : 

- le coût d'exécution C des requêtes de la charge soit minimal, c'est-à-dire : 



- l'espace de stockage des index et des vues de Config ne dépasse pas S, c'est-à-dire : 



Les problèmes de sélection d'index et de vues matérialisées sont connus pour être NP- 
complets Comer (1978); Gupta (1999). De ce fait, il n'existe pas d'algorithme qui propose 
une solution optimale en un temps fini. Plusieurs travaux de recherche proposent des solu- 
tions proches de la solution optimale en utilisant des heuristiques réduisant la complexité du 
problème. 



2 État de Fart 



C/configiQ) = Min (C/oiQ)) ; 





OiEConfig 
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Les travaux traitant la sélection d'index Frank et al. (1992); Choenni et al. (1993a,b); Va- 
lentin et al. (2000); Golfarelli et al. (2002); Dageville et al. (2004) et la sélection de vues 
Gupta (1999); Gupta et Mumick (1999); Baril et Bellahsene (2003); Smith et al (2004); Gupta 
et Mumick (2005) s'orientent dans leur majorité vers une sélection séquentielle des vues et 
des index sur les vues, ou vers une sélection isolée des index ou des vues matérialisées. Ce- 
pendant, les index et les vues matérialisées sont fondamentalement des structures physiques 
similaires Agrawal et al. (2000). En effet, les deux structures sont redondantes, accélèrent le 
temps d'exécution des requêtes, partagent la même ressource de stockage et impliquent une 
surcharge de maintenance pour le système suite aux mises à jour des données. Les vues et les 
index peuvent alors être en interaction. La présence d'un index sur une vue matérialisée peut 
en effet rendre celle-ci plus "attractive" et yice versa. 

Peu de travaux se sont portés sur la sélection simultanée des vues matérialisées et des 
index. Agrawal et al. ont proposé trois alternatives pour l'énumération conjointe de l'espace 
des index et des vues matérialisées Agrawal et al. (2000). La première alternative, dénotée 
MVFIRST, tend à sélectionner les vues matérialisées en premier, puis les index pour une charge 
donnée en présence des vues préalablement sélectionnées. La deuxième alternative, dénotée 
INDFIRST, sélectionne en premier les index, puis les vues. La troisième alternative, dénotée 
joint enumeration, traite la sélection des index, des vues matérialisées et des index sur ces vues 
en une seule itération. Les auteurs affirment qu'elle est plus efficace que les deux premières. 

Bellatreche et al. ont traité le problème de distribution de l'espace de stockage entre les 
vues matérialisées et les index de manière itérative afin de minimiser le coût total d'exécution 
des requêtes d'une charge donnée Bellatreche et al. (2000). Un ensemble de vues et d'index 
est désigné comme une solution initiale au problème de sélection d'index et de vues. L'ap- 
proche reconsidère itérativement la solution initiale dans le but de réduire davantage le coût 
d'exécution des requêtes en redistribuant l'espace de stockage entre les vues et les index. Elle 
s'appuie sur une compétition perpétuelle entre deux agents, l'espion des index et l'espion des 
vues. L'espion des index (respectivement, des vues) vole de l'espace réservé pour stocker les 
vues (respectivement, les index). L'espace ainsi récupéré est utilisé pour créer d'autres index 
à la place des vues élaguées, suivant des politiques de remplacement. L'opération est validée 
si le coût d'exécution des requêtes est réduit. La sélection d'index et de vues commence par 
appliquer l'espion qui réduit le plus le coût des requêtes. Le processus de sélection s'arrête 
lorsqu'il n'y a plus de réduction du coût des requêtes. 

Finalement, Rizzi et Saltarelli ont proposé une approche qui détermine a priori un com- 
promis entre l'espace de stockage alloué aux index et aux vues matérialisées en se basant sur 
les requêtes de la charge Rizzi et Saltarelli (2003). L'idée de Rizzi et Saltarelli est que le fac- 
teur clé dans l'optimisation des performances des requêtes est leur niveau d'agrégation, défini 
par la liste des attributs de la clause Group by, et la sélectivité des attributs présents dans 
les clauses Having et Where. En effet, la matérialisation offre un grand bénéfice aux re- 
quêtes comportant des agrégations de granularité grossière (nombre faible d'attributs dans la 
clause Group by) car elles génèrent peu de groupes dans un grand nombre de n-uplets et, par 
conséquent, l'accès à une petite vue est moins coûteux que l'accès aux tables de base. D'autre 
part, les index donnent leur meilleur bénéfice avec des requêtes contenant des attributs dont 
la sélectivité est élevée car elles sélectionnent peu de n-uplets et, par conséquent, l'accès à un 
nombre élevé de n-uplets inutiles est évité. Les requêtes avec des agrégations fines et de fortes 
sélectivités encouragent l'indexation. En revanche, les requêtes avec des agrégations grossières 
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et de faibles sélectivités encouragent la matérialisation. 

Le défaut que nous identifions dans les travaux de Bellatreche et al. et de Rizzi et Saltarelli 
est qu'ils ne prennent pas en compte les interactions entre les vues matérialisées et les index. En 
effet, les deux types de structures y sont sélectionnés de manière concurrente et non conjointe. 
Or, des index sur les vues matérialisées déjà sélectionnées peuvent s'avérer des options très 
intéressantes. Notre approche s'apparente donc à celle d'Agrawal et al. (joint enumeration). 
Cependant, ses auteurs ne donnent malheureusement aucun détail sur son fonctionnement, ce 
qui rend toute comparaison (y compris expérimentale) impossible. 

3 Sélection simultanée d'index et de vues 
matérialisées 

Le principe général de notre stratégie de sélection simultanée d'index et de vues matériali- 
sées est représenté à la Figure 1. Rappelons qu'une vue matérialisée est une requête nommée 
dont les données sont stockées sur disque sous la forme d'une table. La sélection d'index peut 
donc se faire sur les tables de base ainsi que sur les vues matérialisées. Nous procédons comme 
suit pour proposer une configuration d'index et de vues matérialisées pertinents : 

- extraction d'une charge des requêtes représentative, 

- construction de l'ensemble des vues matérialisées candidates à partir de la charge, 

- construction de l'ensemble des index candidats à partir de la charge et des vues matéria- 
lisées candidates, 

- sélection simultanée d'index et de vues matérialisées, 

- construction de la configuration finale d'index et de vues matérialisées. 

L'extraction de la charge en entrée de notre approche s'effectue à partir du journal des re- 
quêtes exécutées sur les données de l'entrepôt. La charge que nous considérons est un ensemble 
de requêtes de projection, sélection et jointure. De telles requêtes sont composées d'opérations 
de jointures, de prédicats de sélection et d'opérations d'agrégation. Nous appliquons ensuite 
une stratégie de sélection isolée de vues matérialisées que nous avons développée et qui est ba- 
sée sur la classification non supervisée des requêtes Aouiche (2005). Cela permet de construire 
un ensemble de vues candidates pertinent pour la charge. La classification des requêtes peut 
être vue comme une sorte de compression de la charge Chaudhuri et al. (2002). Cela permet 
d'assurer la scalabilité de notre approche. En effet, les charges ont tendance à être volumi- 
neuses et leur coût de traitement est par conséquence important. Au lieu de réaliser l'optimi- 
sation directement à partir de la charge, il est plus judicieux de le faire à partir d'une charge 
compressée qui conserve les relations existant entre les requêtes de la charge initiale. 

Nous avons également développé une stratégie de sélection isolée d'index basée sur la 
recherche de motifs fréquents fermés Aouiche et al. (2003, 2005), qui permet de construire un 
ensemble d'index pertinent pour les requêtes de la charge et les vues matérialisées candidates 
générées à l'étape précédente. Notons que, notre approche étant modulaire, nous pourrions 
utiliser toute autre méthode de sélection isolée d'index ou de vues matérialisées. Finalement, 
nous appliquons notre stratégie de sélection simultanée de vues matérialisées et d'index, que 
nous détaillons dans les sections suivantes. 

Afin d'illustrer notre propos, nous nous basons sur la charge de requêtes de la Figure 2 et 
les vues matérialisées et les index candidats qui en découlent (Figures 3 et 4, respectivement). 



N. Maiz et al. 



Métadonnées ~1 
Schéma, statistiques... i 







Charge 



Entrepôt de données 



Ensemble de vues 






matérialisées candidates 






i © 




Ensemble 




Ensemble 


d'index candidats 




d'index candidats 



Modèles 
de coût 



Configuration finale 
de vues matérialisées et d'index 



I Sélection simultanée d'index 
et de vues matérialisées 



Extraction des requêtes résolues par le système 

©Sélection des vues matérialisées candidates ^ . , , ^ . ^ , 

à partir des requêtes de la charge (s) Construction de la configuration finale 

^ de vues matenalisees et d index 





Sélection d'index candidats à partir des requêtes 
de la charge et des vues matérialisées candidates 



FiG. 1 - Principe de notre sélection simultanée d'index et de vues matérialisées 



Nous modélisons les relations existant entre les requêtes, les vues matérialisées et les index 
candidats à l'aide de trois matrices : requêtes-vues, requêtes-index et vues-index, que nous 
décrivons dans les sections suivantes. 



3.1 Matrice requêtes-vues 

La matrice requêtes-vues modélise les relations entre les requêtes de la charge et les vues 
matérialisées qui en sont extraites, c'est-à-dire les vues exploitées par au moins une requête 
de la charge. Cette matrice peut être vue comme le résultat de la réécriture des requêtes de la 
charge en fonction des vues matérialisées. Les lignes et les colonnes de cette matrice sont les 
requêtes de la charge et les vues matérialisées recommandées par notre stratégie de sélection 
de vues, respectivement. Le terme général de la matrice est égal à un si une requête donnée 
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exploite une vue et à zéro sinon. Le Tableau 1 illustre un exemple de matrice requêtes-vues 
composée de huit requêtes et de neuf vues matérialisées recommandées pour ces requêtes. 





Select sales. time_id, sum(amount_sold) 
from sales, times 

where sales. time_id - times. time_id 
and times. time_fiscal_year = 2000 
group by sales. time_id 


95 


select promotions. promo_name, 

sum(amount_sold) 

from sales, promotions 

where sales. promo_id = promotions.promo_id 
and promotions.promo_begin_date='30/01/2000' 
and promotions.promo_end_date= '30/03/2000' 
group by promotions .promo_name 




Select sales. prod_id, 

sum(amount_sold) 

from sales, products, promotions 

where sales.prod_id = products. prod_id 

and sales. promo_id = promotions. promo_id 

and promotions .promo_category = 'news paper' 

group by sales. prod_id 
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select customers .cust_marital_status, 
sum(quantity_sold) 
from sales, customers, products 
where sales. cust_id = customers. cust_id 
and sales.prod_id = products. prod_id 
and customers. cust_gender = 'woman' 
and products.prod_name = 'shampooing' 
group by customers.cust_first_name 




Select customers.cust_gender, sum(amount_sold) 

from sales, customers, products, 

where sales. cust_id = customers. cust_id 

and sales.prod_id = products. prod_id 

and customers. cust_marital_status =' single' 

and products. prod_category = 'women' 

group by customers.cust_gender 
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select products. prod_name, sum(amount_sold) 
from sales, products, promotions 
where sales. prod_id = products. prod_id 
and sales. promo_id =promotions.promo_id 
and products. prod_category=:'tee shirt' 
and promotions.promo_end_date= '30/04/2000' 
group by products .prod_name 


94 


select products. prod_name, sum(amount_sold) 
from sales, products, promotions 
where sales.prod_id = products. prod_id 
and sales. promojd = promotions. prom_id 
and promotions. promo_category = 'TV 
group by products .prod_name 


98 


select channels.channel_desc, sum(quantity_sold) 
from sales, channels 

where sales. channel_id = channels. channel_id 
and channels.channel_class = 'Internet' 
group by channels.channel_desc 



FiG. 2 - Exemple de charge 
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index attributs indexés 



il 


promotions.promo_category 


12 


channels.channel_desc 


is 


channels . channel_clas s 


14 


customers . cust_marital_status 


ib 


customers . cust_gender 


IQ 


times .time_begin_date 


il 


times .time_end_date 


is 


times.fiscal_year 


19 


products .prod_name 


ilo 


products .prod_category 


iii 


promotions .promo_name 


ii2 


customers . eu st_fir st_name 



FiG. 4 - Index candidats 
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Tab. 1 - Matrice requêtes-vues 



3.2 Matrice requêtes-index 

La matrice requêtes-index permet d'identifier les index construits sur les tables de la base. 
La matrice requêtes -index peut être vue comme la réécriture des requêtes de la charge en 
fonction des index recommandés par un algorithme de sélection d'index. Les lignes et les 
colonnes de cette matrice sont respectivement les requêtes de la charge et les index sélectionnés 
à partir de cette charge. Le terme général de la matrice est égal à un si une requête donnée 
exploite un index et à zéro sinon. Le Tableau 2 illustre un exemple de matrice requêtes-index 
composée de huit requêtes et de douze index recommandés pour ces requêtes. 

3.3 Matrice vues-index 

La matrice vues-index identifie les index construits sur les vues matérialisées recomman- 
dées par l'algorithme de sélection de vues. Les lignes et les colonnes de cette matrice sont 
respectivement les vues matérialisées candidates préalablement sélectionnées et les index can- 
didats recommandés pour ces vues. Le terme général de la matrice est égal à un si une vue 
donnée exploite un index et à zéro sinon. Le Tableau 3 illustre un exemple de matrice vues- 
index composée de sept vues et de douze index recommandés pour ces vues. 
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Tab . 2 - Matrice requêtes -index 





n 


i2 




ù 






n 


^8 




no 


ni 


ii2 

























1 














V2 





1 
































V3 











1 


1 











1 


1 





1 


V4 


1 























1 


1 








Vb 


1 


























1 








V6 





1 


1 

















1 


1 








V7 





1 











1 


1 





1 


1 


1 






Tab. 3 - Matrice vue s -index 



4 Modèles de coût 

Généralement, le nombre d'index et de vues candidats est d'autant plus important que 
la charge en entrée est volumineuse. La création de tous ces index et vues peut ne pas être 
réalisable en pratique à cause de la contrainte définie sur l'espace de stockage alloué aux index 
et vues. Pour pallier ces limitations, nous exploitons des modèles de coût permettant de ne 
conserver que les index et les vues les plus avantageux. Ces modèles estiment l'espace en 
octets occupé par les index et les vues, les coûts d'accès aux données à travers ces index et/ou 
ces vues et le coût de leur maintenance en terme de nombre d'entrées/sorties. 

Nous avons développé des modèles qui estiment le coût d'accès aux données à travers 
des index bitmap de jointure, ainsi que les coûts de maintenance et de stockage de ces in- 
dex Aouiche et al (2005). Nous avons également présenté des modèles qui estiment le coût 
d'accès aux données à travers des vues matérialisées, ainsi que les coûts de maintenance et de 
stockage de ces vues. Dans la suite de la section, nous ne développons donc que les nouveaux 
modèles de coût développés pour ce travail relatifs aux index en B-arbre. 

5 Calcul du bénéfice de matérialisation et d'indexation 

Le bénéfice apporté par la sélection d'un objet (index, vue matérialisée ou vue matérialisée 
avec index) est défini conmie la différence entre le coût des requêtes de la charge à un moment 
donné et le coût de ces mêmes requêtes suite à l'ajout de cet objet. 
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Soient Q une charge de requêtes et Config une configuration composée de vues matériali- 
sées et d'index construits sur les tables de base ou les vues. QI, QV et VI sont respectivement 
les matrices requêtes-index, requêtes-vues et vues-index. Nous développons dans les sections 
suivantes le calcul du bénéfice pour un index ou une vue matérialisée. 



5.1 Bénéfice apporté par un index 

L'ajout d'un index à la configuration Config peut conduire à plusieurs alternatives résu- 
mées dans le Tableau 4. En effet, l'ajout d'un index donné à la configuration Config peut 
améliorer de façon directe le coût des requêtes de la charge ou indirectement à travers des vues 
auxquelles cet index est associé. 





VI[v,i] = 1 


VI[v,i] = 


V G Config 


min (bénéfice de matérialisation, bénéfice 
d'indexation de v) 


bénéfice d'indexation 


V ^ Config 




bénéfice d'indexation 



Tab. 4 - Bénéfice apporté par F ajout d'index 



Le bénéfice d'indexation apporté par l'ajout d'un index i est calculé conmie suit : 



r CiQ,Cor^fi9)-CiQ,ConfiglJ{i}) si\/v E V, V I[v , i] = 0, 

I tatlle{^t) ' L ' j 

benefice(Q, ConfigU{i}) = l ^^J^^^^a^^^^^^ V = {v E Config, VI[v, i] = 1} / 

I sinon. 



5.2 Bénéfice apporté par une vue matériaUsée 

L'ajout d'une vue matérialisée à la configuration Config peut conduire aux alternatives 
résumées dans le Tableau 5. En effet, l'ajout d'une vue donnée à la configuration Config peut 
améliorer de façon directe le coût des requêtes de la charge ou de façon collaborative avec les 
index associés à cette vue. 





VI[v,i] = 1 


VI[v,i] =0 


i G Config 




bénéfice d'indexation 


i ^ Config 


min (bénéfice d'indexation, bénéfice de 
matérialisation) 


bénéfice de matérialisation 



Tab. 5 - Bénéfice apporté par l'ajout de vue 



Le bénéfice de matérialisation apporté par la vue matérialisée v est calculé comme suit : 



beneficeiQ, ConfigU{v}) = > si I' = {i e Config, VI[v, i] = 1} # ( 

I sinon. 
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6 Algorithme de sélection simultanée d'index et de vues ma- 
térialisées 

Notre algorithme de sélection d'index et de vues matérialisée (Algorithme 1) est basé sur 
une recherche gloutonne dans l'ensemble O des objets obtenus en réalisant l'union de l'en- 
semble d'index candidats / et de l'ensemble de vues candidates V {O = I \J V). Soir la 
fonction objectif F définie comme suit : 



F/Config{{Oi}) = bénéfice(Q, Config U ({oj)) - (3Cmaitenance{{0i}) 

OÙ Oi peut être un index ou une vue et f3 = \Q\ p{oi) estime le nombre de mises à jour 
de Oi. La probabilité de mise à jour p{oi) est égale à nombre d-éiLents de o ^gl^™' » le 
ratio représente la proportion de rafraîchissement par rapport à la proportion 

d'interrogation de l'entrepôt de données. 



Algorithme 1 Sélection simultanée de vues matérialisées et d'index 
Config ^ 
O^IUV 
répéter 

taille{omax) ^ 
beneficcmax ^ 
pour tout Oi e O — Config faire 

alors 

beneficCmax ^ Fconfig({Oi}) 

Omax ^ argmax(Fcon/i^({oi}) 

{l'ensemble Omax peut contenir des index et des vues matérialisées} 

fin si 
fin pour 

si Fconfig{Omax) > alorS 

si index (omax) = '^^«^^ alors 

tdillei^Ofjiax^ ^ tCLilleiYidexiPmax^ 

sinon 

si vue{omax) = vrai alors 

t(lillc(^OYnax^ tdillCyiiQi^OYnax^ 

sinon 

Omax — "^max U Vjjiax 

tQjillc{OjYi(ix^ tQjillc{OjYi(ix^ ~l~ ^^^^^^indexi^^max^ ~l~ t(^m^vue{,^max^ 

fin si 
fin si 
fin si 

S ^ S - taille{omax) 
Config ^ Config U (omax) 
jusqu'à (Fconfig{omax) < OU O - Config = ou 5 < 0) 
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Soit S l'espace disque alloué par l'administrateur de l'entrepôt de données pour stocker 
les vues matérialisées et les index. À la première itération de notre algorithme, les valeurs 
de la fonction objectif F sont calculées pour chaque index ou vue de l'ensemble O. Le coût 
d'exécution de toutes les requêtes de la charge Q est égal au coût d'exécution de ces requêtes 
à partir des tables de base sans indexation ni vue. L'ensemble o^ax de vues et/ou d'index 
qui maximise F, s'il existe (Fconfig{{omax)} > 0)> est alors ajouté à l'ensemble Config 
si l'espace de stockage S n'est pas atteint. Si l'ajout est fructueux, l'espace S est diminué de 
l'espace de stockage occupé par Omax- L'espace occupé par Omax dépend de son contenu (index 
et/ou vue). Nous utilisons les fonctions booléennes index (omax) et vue{omax) qui renvoient 
vrai si Omax est un index ou une vue (lignes 15 à 25 de l'Algorithme 1), respectivement. 

Les valeurs de la fonction objectif F sont ensuite recalculées pour chaque élément res- 
tant dans O — Config, car elles dépendent des vues et des index sélectionnés présents dans 
Config. C'est cela qui permet de prendre en compte les interactions qui peuvent exister entre 
les index et les vues matérialisées. Rappelons que cette interaction est implicitement inclue 
dans le calcul du bénéfice, qui exploite les matrices requêtes-index QI, requêtes- vues et 
vues-index VI. 

Nous répétons ces itérations jusqu'à ce qu'il n'y ait plus d'amélioration de la fonction ob- 
jectif (F/config{omax) < 0)? QUC tous Ics iudcx et vucs aient été sélectionnés (O — Config = 
0) ou que la limite d'espace de stockage soit atteinte (S < 0). 

7 Expérimentations 

Afin de valider notre stratégie de sélection simultanée d'index et de vues matérialisées, 
nous l'avons expérimentée sur un entrepôt de données test implanté au sein du SGBD Oracle 9i. 
Nos expérimentations ont été réalisées sur un PC sous Windows XP Pro doté d'un processeur 
Pentium 4 à 2.4 GHz, d'une mémoire centrale de 512 Mo et d'un disque dur IDE de 120 Go. 

Notre entrepôt de données test est composé d'une table de faits Sales et de cinq tables 
dimensions Customers, Products, Promotions, Times et Channels. Le Tableau 6 
détaille le nombre de n-uplets et la taille en Mo de chacune des tables de cet entrepôt. 



Table 


Nombre de n-uplets 


Taille (Mo) 


Sales 


16 260 336 


372,17 


Customers 


50 000 


6,67 


Products 


10 000 


2,28 


Times 


1 461 


0,20 


Promotions 


501 


0,04 


Channels 


5 


0,000 1 



Tab. 6 - Caractéristiques de V entrepôt de données test 



Nous avons mesuré le temps d'exécution des requêtes de la charge de la Figure 2 dans les 
cas suivants : sans index ni vue matérialisée, avec vues matérialisées, et avec index et vues 
matérialisées. La Figure 5 représente la variation de ce temps de réponse en fonction du pour- 
centage d'espace de stockage utilisé. Ce pourcentage est calculé par rapport à l'espace total 
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FiG. 5 - Résultats expérimentaux 



occupé par tous les index et les vues obtenus en appliquant notre stratégie sans définir au- 
cune contrainte d'espace. Afin de mieux visualiser les résultats, nous avons utilisé une échelle 
logarithmique sur l'axe des abscisses. 

La Figure 5 montre que pour les valeurs élevées de l'espace de stockage, la sélection simul- 
tanée d'index et de vues est meilleure que la sélection isolée des index et vues. En revanche, 
nous constatons que pour les petites valeurs de l'espace de stockage, il peut arriver que la sé- 
lection d'index soit plus performante que la sélection simultanée d'index et de vues. Cela peut 
être expliqué par le fait qu'en général, la taille des index est significativement moins impor- 
tante que celle des vues. Dans ce cas, on peut mettre dans le même espace (de petite taille) plus 
d'index que de vues et ainsi améliorer davantage le temps de réponse. En effet, intuitivement, 
plus on dispose d'index, plus on améliore les performances. Or, ce point n'avait pas été mis en 
lumière par les travaux antérieurs aux nôtres. 



8 Conclusion et perspectives 

Nous avons proposé dans cet article une nouvelle démarche de sélection simultanée d'in- 
dex et de vues matérialisées dans les entrepôts de données. Notre approche prend réellement 
en compte l'interaction qui peut exister entre les index et les vues matérialisées et les traite 
simultanément afin de réduire le coût d'exécution de requêtes. Cela donne lieu à une sélection 
optimale des vues et des index en fonction de l'espace de stockage qui leur est alloué. En effet, 
nos résultats expérimentaux montrent que la sélection simultanée de vues matérialisées et d'in- 
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dex est plus performante que la sélection isolée de ces structures lorsque l'espace de stockage 
est raisonnablement grand. 

Les perspectives ouvertes par ces travaux sont de plusieurs ordres. Tout d'abord, il est 
nécessaire de poursuivre nos expérimentations afin de confronter notre approche à l'existant. 
Malheureusement, la proposition joint enumeration d'Agrawal et al. , qui est la plus proche 
de la nôtre, n'est pas suffisamment documentée pour que nous puissions mener une telle étude 
à bien. En revanche, comparer nos travaux à ceux de Bellatreche et al , à la fois en termes 
de gains de performance et de surcharge pour le système, pourrait nous permettre d'établir 
définitivement que la sélection conjointe d'index et de vues matérialisées est plus intéressante 
que leur sélection concurrente. 

Par ailleurs, cette stratégie d'optimisation des performances s'applique dans un cas sta- 
tique. La charge sur laquelle est effectuée l'optimisation peut devenir obsolète au bout d'un 
temps donné. Lorsque cela arrive, il faut resélectionner les index et les vues matérialisées. Les 
travaux traitant de la détection de sessions basés sur le calcul d'entropie Yao et al (2005) pour- 
raient s'appliquer pour déterminer le moment oii il faut lancer la resélection des index et des 
vues. 

Dans ces travaux, nous nous sommes également positionnés dans le cas oii l'administrateur 
optimise les requêtes adressées au système par tous les utilisateurs confondus. Or, les besoins 
définis par différents profils d'utilisateurs (dans le cas des systèmes multi-utilisateurs) sont 
différents. Il serait donc plus pertinent d'appliquer nos stratégies sur des groupes de requêtes 
définis par les utilisateurs identifiés dans chaque profil. 

Finalement, nous nous sommes restreints à utiliser seulement les index et les vues matéria- 
lisées comme mécanismes d'optimisation des performances. Or, d'autres structures de données 
peuvent être intégrées ou couplées avec les index et les vues, comme par exemple la gestion 
de cache, le regroupement et le partitionnement (fragmentation) Agrawal et al. (2004); Zilio et 
al. (2004); Bellatreche et al. (2005). 
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Summary 

Indices and materialized views are physical structures that accelerate data access in data 
warehouses. However, thèse data structures generate some maintenance overhead. They also 
share the same storage space. The existing studies about index and materialized view sélection 
consider thèse structures separately. In this paper, we adopt the opposite stance and couple 
index and materialized view sélection to take into account the interactions between them and 
achieve an efficient storage space sharing. We develop cost models that evaluate the respective 
benefit of indexing and view materialization. Thèse cost models are then exploited by a greedy 
algorithm to select a relevant configuration of indices and materialized views. Expérimental 
results show that our strategy performs better than the independent sélection of indices and 
materialized views. 



